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I hope I got your attention with 
the slight cover changes and the 
"CoCo 2000" headline. Basi- 
cally, I am committing to produc- 
ing this magazine through the 
year 2000. That is about three 
more years. Where we go be- 
yond that is up to you, the read- 
ers and subscribers. As long as 
I have interesting things to print 
and enough subscribers to 
make the work worthwhile, weMI 
continue printing even after 
2000. 

What is worthwhile? We start 
our fifth year of publication with 
this issue. In this time, I have 
posted profits twice, the best 
year (nothing broke and had to 
be replaced!) was the last one 
at about $1 ,000. Previously Tve 
posted maybe $250 in profits. 

I said "profit", but I mean that 
very loosely! That is basically 
what I got out of printing the 
magazine. I have upgraded my 
computer equipment several 
times in order to make publish- 
ing easier, and have had to re- 
place a few items that just quit. 
Of course I use my equipment 



for other things, so I get a little 
pay-back by having a little extra 
money to buy better equipment 
than I may otherwise have. But 
I pay myself nothing. 

That profit mentioned is basi- 
cally the magazine's surplus, 
which is held just in case some- 
thing does break or I feel that 
something needs to be up- 
graded. Very rarely I will make 
a personal purchase from my 
business account that I can't 
write off as a business expense. 
That is all I get for producing the 
magazine. And this is mostly off- 
set for the expenses I have at 
home (like the extra power, 
some telephone time, etc.). 

The first two years had eight 
issues, the last two six. So that 
is 28 issues altogether. It takes 
an average of 30 hours work to 
produce, assemble, and mail 
each issue. That comes to a to- 
tal of 840 hours of labor. Divide 
$1250 by 840 and you get $1 .50 
per hour. 

While this is hardly enough to 
think about making the maga- 
zine, there are peripheral re- 



wards. One already mentioned 
is that my computer equipment 
is a total business write-off. So I 
get my computer stuff basically 
for free. Then there are the trips 
to Chicago and other fests. 90% 
of the expenses come from my 
business account. And there are 
the contacts with subscribers, 
and the joy of providing some- 
thing useful for others. 

I have to admit, I don't print this 
magazine for the money! It does 
a little better than break even. 
That is enough for what is basi- 
cally a hobby business. I just 
hope you appreciate the fact that 
I am willing to go to so much 
trouble for so little by continu- 
ing to subscribe and support 
others who work for as little or 
even less (such as Glenside 
CoCo Club and Ron Bull, who 
put on 'fests this year) to sup- 
port the CoCo and OS-9 hobby- 
ist communities. 
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Reader's WritGrnrnm 



From a longtime supporter... 

Enclosed is an American Money Order 
to continue my subscription to "the world 
of 68' micros" magazine. 1 hope I am not 
to late. 

1 have had quite an unusual year (since 
last Sept. at least!). My husband's health 
is not to good: angina from heart attacks 
and other "interior problems'. For myself 
at 81, I have had my share of problems. 
So we decided to move to a retirement 
home. Its a wonderful pampered life, but 
very quiet and satisfying in an indepen- 
dent apartment 

I have to say that we had to exchange 
my beloved CoCo 2 and 3 plus my won- 
derful gem of a PC2 for a Compaq with 
Windows 95. 1 am not quite used to it (from 
Disk BASIC and OS-9 to MS-DOS). I find 
it boring to "click" on all those dialog boxes 
and lines. CoCo 3 was so fast and I could 
"program" v^at I wanted! My husband kept 
his laptop (Tandy HD1100). he uses it for 
Deskmate (fast and easy to operate). 

So here we are. I have given ALL my 
Tandy programs, literature, Rainbow, etc., 
to a specialist in computers v^o loves the 
CoCo. He looks after the Compaq and will 
connect it to the Internet sometime later, 
after I am more installed in our new apart- 
ment. 

I shall miss the CoCo to the end of my 
life, just like I missed the Rainbow when it 
disappeared. 

Frank, alt my best wishes go to all of 
you who have kept faith with the CoCo. 
As you say, though, space on the desk may 
push it out.. 

Thanks for the wonderful work you do, 
and 1 hope to be around to enjoy it many, 
many years to come! 

Mrs. Lyone Boutt 

420 Mackay Street Apt 405 

Ottawa, Ontario K1M 2C4 

CANADA 

Mrs. Bou^, I thank you very much for ail 
the compliments. You have been a patron 
of the CoCo community for a long time... I 
know you have every issue I've ever put 
out and bought nearly every program in 
my catalog! It is great to learn so much 
more about you in this letterf My paternal 
grandmother, whom I love dearly (I'm her 
favorite also!), turned 82 this year Your 
handwriting reminds me very much of hers! 

Don 't fref about your CoCo though. . . you 
can STILL enjoy it on your Compaq! You 
should have received a copy of the CoCo 
3 emulator that I sent you. I discovered 
that I owed you from the defunct 
"microdisk'' subscription. I hope you find 



the emulator to be of value! When you are 
having trouble teaching" your Compaq to 
work as you want it to, and not the other 
way around, fire up the CoCo 3 emulator 
and let it do all the work! Depending on 
the speed of your Compaq, you shouki find 
the emulator to be faster than the original 
CoCo 3. This will let you enjoy your CoCo 
for many more years to come! 

I encourage all to send there best wishes 
to you in your new home, and prayers for 
both of you for continued good health and 
speedy recovery from the surgeries you 
have had. 

Year 2000 Revisited 

1 was glad to see the article by Robert 
Gault in the latest issue, on the "year 2000' 
problem. I've been wondering vy^y there's 
been nothing on that HI now in the OS-9 
community, v^en its such a big deal else- 
where. 

On that subject, I would like some bet- 
ter programmers to tell me why the fol- 
lowing idea wouldn't work: 

OK, so there's only one byte available 
for storing the year in disk identification 
sectors, file descriptor sectors, and OS- 
9's direct page. But one byte can count 
up to 255, which is a lot more years than 
my CoCo Is going to last Instead of stor- 
ing in that byte 

VAL (RIGHTS (YEARSTRING$,2)) 

why not store the value 

(VAL(YEARSTRING$))-1900 

Its backwardty compatible, it will last 
until the year 2155, it presences the integ- 
rity of date comparisons between differ- 
ent files. Main question: Will OS-9 choke 
on a byte greater than 99? Obviously the 
setime and date modules, and other utilh 
ties that print out dates like dir and free 
will have to be altered, but format and the 
file creation/modification modules might 
just work without change, since they prob- 
ably just copy the year byte from direct 
page. There's a good chance that a lot of 
application software won't notice; after all, 
if a programmer thought the year 2000 
would never come, why would he error 
check for values greater than 99? 

Sincerely, 

Richard S. Bair 

335 Jefferson Ave. 

Glencoe. IL 60022-1823 

Well Richard, you have me stumped! 
Looks like it shouki work, at least until 21 55, 
as you stated! Anything from you OS-9 
programmers? Please let us kr)ow and it 
will be printed here! 



Need some drives 

First of all, I hope everything is fine over 
there. Although I don't use my CoCo3 as 
much as I used to, I still use It to do all of 
my data communications chores, to play 
some games, and to try to learn OS-9, 
which I think is the best of the multi-task- 
ing operating systems. Hope no one in 
Microsoft reads this, because I am going 
to a job interview installing Internet sen/- 
ers running NT 4.0 at the local offices of 
Microsoft. 

I hope that you continue to puk)lish ar- 
ticles regarding hardware projects for the 
CoCo, and articles about the AT306 sys- 
tems. I would like to buy one of these when 
my budget lets me. I find these kinds of 
articles really interesting. 

I am looking for two good 5 1/4 drives, 
and one 3 1/2 720K drive. I need them to 
replace the one in my FD-502 nit which 
has a damaged head, and the 720K 3 1/2 
unit to use as a second drive for OS-9. 
The other 5 1/4 is for an old Leading Edge 
XT computer that I want to repair. I hope 
you or any of your readers can help me. 
Thanks for your help and continue the good 
job. 

Your friend, 

Luis E. Tanon 

Los Arcos de Suchville, Apt 217 

Ton-e Sur, Peurto Rico 00966 

Ijjis, one source for good used, guar- 
anteed 360K 5.25" and 720K 3.5" drives is 
Alltronics, 2300 Zenker Road, San Jose, 
CA 95131-1114, 408-943-9773 (www. 
alttronics.com). Also try Alltech Electron- 
ics, 619-724-2404 (CA, www.allelec.com). 
Prices range from $5-S25. Make sure you 
get a 720K 3.5" drive and NOT a 1.4M! 
The 1.4M may work correctly as a 720K in 
a PC, but NOT in the CoCoU 
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A Missed CoCoFest? David Baker & Ted Willi 

The "First Annual 'Last' CoCoFest of the Clarke County CoCo Club" 



Athens. GA (June 23, 1997) - It 
took a good part of the longest day 
of this year to hold the First Annual 
"Last" CoCoFest of the Clarke 
County Color Computer Club 
(CCCCC) in Athens on June 21, 
1997. When it was all over both 
club members unanimously de- 
clared it had been productive, prof- 
itable, and probably worth doing 
again someday. 

Member Ted Willi showed up 
promptly at 6 PM at the residence 
of member David Baker, who was 
already there. Ted brought three 
CoCo2's, four monochrome moni- 
tors, including a Magnavox of ex- 
ceptionally fine quality, and as- 
sorted software, hardware and 
reading material for consideration. 
Member Baker tried unsuccessfully 
to unload a disabled Panasonic 24- 
pin DMP printer on member Willi. 
However, it was determined later 



From: Dennis Batbory-Kitsz 

Hi folks! I've been hiding out 
in Vermont, but since it's the 
10th anniveisaxy of my com- 
pany Gxeen Mountain Micro's 
demise, I thought it might be 
time to put in an appearance 
here. 

About 150 copies of 'Learn- 
ing the 6809' (book only) re- 
main, which I'd be happy to 
offer at $10 postpaid to any- 
one interested. If at least 10 
people also want the original 
tapes, I'd be pleased to make 
up a set of those as welL 

One of these days 111 tell my 
own tale ... amusing indeed... 

Dennis Bathory-Kitsz 
RD 2 Box 2770 
Cox Brook Road 
Northfield, Vermont 05663 

<bathory@nialtedmedia.com> 

Malted/Media: 

http://www. maltedmedia.com/ 



that Ted had a probable future use 
for a VGA adapter card that Dave 
no longer needed, as one is re- 
quired to get a CoCo3 emulator 
running on a VGA monitor some- 
where pretty soon. Also, David 
gave Ted a compact color TV, 
which doubles as a CoCo3 moni- 
tor, with the caveat that any attempt 
to watch any TV show other than 
Braves games and other culturally 
uplifting programs will cause any 
CoCo in the vicinity to crash 
promptly and permanently. 

The highlight of the CCCCC's 
First Annual Tasf CoCoFest was 
the swift and sure manner in which 
one of the club's members (Ted 
Willi) installed a Baker's CoCo3 
emulator on a PC- so competently 
that it worked con"ectly right away. 
Unfortunately, member David, who 
had been cutting grass and doing 
other yard work for much of the 
day, was taking a shower at the 
time and missed the whole instal- 
lation. Later, though, both club- 
members agreed that Jeff 
Vavasour has done not only a great 
service for the entire Color Com- 
puter community but is also one 
heckuva smart guy. 

Around 9:30 PM the members 
took a break for refreshments, 
which consisted of some sloppy 
hotdogs with Vidalia onions and 
chips and some fat-free but not 
calorie-free ice cream, and viewed 
the last few innings of a somewhat 
sloppily played Braves-Phillies 
game. 

After the lunch break the entire 
membership returned to the Com- 
puter Room, scene of the hottest 
activity at the CoCoFest, where 
David beamed aboard the Internet 
and showed Ted the mother of all 
CoCo web sites from Saskatoon, 
Saskatchewan and pointed out the 
link to Al Dages's web page. A side 



excursion was made to member 
Baker's Usenet subscriptions, 
where he and willi read several 
hundred postings from comp.os. 
os9, comp.sys.m6809, bitlistserv. 
coco, and comp.sys.tandy. After- 
wards Ted logged onto his Delphi 
account by using the Telnet facility 
on Dave's PC. 

Finally after midnight the club 
members gathered up their CoCo 
gear to head home (except for any- 
one who was already there) and 
heartily agreed that this had been 
the very best First Annual "Lasf 
CCCCC CoCoFest ever held in 
Athens! And so, at last the Fest 
wound down with that unique 
CoCo technolust assuaged for the 
moment. But each club member 
knew in his heart that, like a stuck 
disk drive, the compulsion to meet 
and swap CoCo stuff is one that 
never truly times out! 

Note: The Clarice County Color 
Computer Club holds its meetings 
whenever its members can get 
around to it. One of its most active 
members will be moving to Atlanta 
soon, which proves that you don't 
have to live in Athens to be a mem- 
ber. In fact, if you already belong 
to any CoCo club anywhere, you 
are automatically eligible for mem- 
bership in the CCCCC. which has 
already grown to two members in 
only the last few years, probably 
because there are no annual dues. 
This article has been presented in 
lieu of the long-planned club news- 
letter to be published someday 
maybe, (editor Both members are 
subscribers, by the way!) 
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FARN A Systems 

Your most complete source for Color Computer and OS-9 information! 



Fo&t Office Box 321 
Warner l^obins, GA 31099 
Phone: 912-32S-7&59 

E-mail: dsrtfoxtfdelphi.com 



>%z>r:> ^3 -s^fcAy, ^^ <:^.4KJhsxKOJX, ^-ro <:>\^^f^^^.a.^ 



Maet^rin^ 06-9 - ^i60.00 

Complffttfly et<?p6 one through learning all ae- 
p<?cte (7f 06-9 on the Color Computer. Easy 
to follow instruction e and tutorials. With a 
disk full of added utilities and softwarel 

Tandys Ltttle Wond<5r - $25.00 

History, tech info, hacks, echematice, re- 
pairs... almost EVERYTHING available for the 
Cokr Computeri A MUST HAVE for ALL CoCo 
afickTnados. tToth new and old!)) 

Quick Reference Guides 

Handy ifttle books contain the most refer- 
enced Info in easy to find format, Size makes 
them unobtrusive on your desk. Command syn- 
tax, error codes, system calls, etc. 
CoCo OS'S Level II : $5.00 
05'9/e&OOO : t7,00 

Complete Dlsto Schematic set: $15 

Complete set of all Disto product schemat- 
k;6. Great to have... needed far repairsi 



"A Full Turn of the Sen 

Lots of CoCo info. 
Tony PiStefano 



dlde||l»ll 

he^^^^d e: 



^ 



s(t 



)Z0 

iHW tutorials^, by 



-Inside WSK^ ^^ ^^'^ ' ^^O 
ScheA^p^d explanation of how the 2 me^ 
CoCo ^ upgrade works. 



SOFTWARE: 

CoCo Family Recorder: Best ^eneak?^ record 
keeper EVER for the CoCo\ Rec^uires CoCo3, 
two drives (40 track for OS-9) and SO co\5. 
PEC&: *15.00 OS-9: $20.00 

PI^ITech rro: $10.00 

Add sounds to your BASIC and M/L pro^ramsl 
Very easy to use. Reciuires user to make a 
simple cable for sound Input through a Joy- 
stick port. Requires CoCo5, DEC0, 5121;. 

ADOS: Most respected enhancement for 
PECBl Double sided drives. 40/30 tracks, fast 
formaXe, many extra and enhanced commandsl 
Original (CoCo \/2J3) : $10.00 
ADOS 5 {CoCo 3 only) : $20.00 
Extended ADOS 3 {CoCo 3 only, reciuires 
ADOS 3. support for 512ls-2MB, RAM drives. 
40/dO track drives mixed) : $30.00 
ADOS 3/EADOS 3 Combo: $40.00 

rbcel Blaster - $12,00 
Hi^h speed graphics tools for CoCo 3 OS-9 
Level II. Easily speed up performance of your 
graphics programs! Designed especially for 
game programmers! 

ratch OS-9 - ^.OO 

Latest verskms of all popular utils and new 
commands with complete documentation. 
Auto-installer reciuires 2 40T DS drives (one 
may be larger). 



NEW ITEMSai 

FAKNA System© \& pSesk&f^d to 
sir\nour{CG that w<5 are r\ow d{&' 
tribut^rs of th<5 following, for- 
merly from HorXMcrrx Exposurel 
Note: If you r\cs/cr rcccWoA your or- 
d<ir from NX, &&nd a copy of your 
canc^W^ei ch«ck a\ar\0 with $5 to 
caver 3&H and I'll ftil the orderl 

NttrOS-9 : $35.00 

A complete rewrite of OS-9 Level 11 that takes 
advantage of all features of Hitachfs 6309 
proceeeor. Easy install script! 6309 recjuired. 

Tuneiip : $20.00 

If you dont have a 6309. you can still take 
advantage of some of the Nitro software tech- 
nok>gyl Many OS-9 Level it modules rewritten 
for improved epeed with the stock 6&09\ 

Thexder 06-9 

Shanghai OS-9 : $25.00 each 

Transfers your ROM Pack game code to an 
OS-9 diskl riease send manual or ROM Pack 
to verify ownership of original 

Rusty : $20.00 

Launch DECB programs from OS-9! Allows 
k)ading of some programs from hard drivel 



FARNA-11123 Includes: 

2MB RAM 

300MB Hard Drive (was 2001)* 

Trident 8900 1MB Video Card 

$960.75 



FARNA-11225 Includes: 

2MB RAM 

500MB Hard Drive* 

Tseng W32i 1MB Video Card 

$1114.47 



F/\K.N/\ Systems /\T30^ B^se^ Com putters 

Complete computer eys'Dems \?aeed on the AT306 board from Kraider Electronics. Systems are 
completely setup and ready to qo. Just add a VGA monitor {or we can supply that too)l 

Both systems include: 

16 bit PC/AT I/O bus with five slots 

MC68306 CPU at 16.67MH2 

4 30 pin SIMM sockets 

IDE Hard Drive interface 

1.4MB Floppy Drive 

Two 16 byte fast serial ports (up to 115K baud) 

Bidirectional parallel printer port 

ReaMJme clock 

PC/AT keyboard 

Desktop Case arxJ Power Supply 

(mini-tower case optional, no costi) 
MGR Graptik^l Windowing Environment 

with full documentatk)n 
"Personar OS-9/68000 Vr 3.0 
' (Industrial with RBF) 
Drivers for Tseng W32i 

and Trklent 8900 VGA cards 
Drivers for Future Domain 1680 

and Adaptec AAHISxx SCSI cards 

Many other utilities and tools 



niti9 Is the SMAUEST amount of toanaOBd space Bvallabte, 
Prices fluctuate- we get you the largest Mvepossltile for the inoneyallottedl 



HACKERS MINI KIT (FARNA-11100): Includes AT306 board, OS-9 and drivers, 
util software, assembly instructions/tips, T8900 1MB video card. Add your own 
vkE5h3Qid,driws6,andmociiD(ri ONLY$SOOI ^^ 



Call for a quote on different configurations and components. 
Warranty Is 90 days for labor & setup, components limited to manutacturers warranty. 

Microware Programmers Package - 

Licensed copies of Microware C compiler, Assembler, Debugger, 

and many other tools 1 

Wftfi system purchase: $65.00 Without systetn: $85.00 
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operating system nine 

A paper on the CoCo4 - RFC 



Rick Ulland 



Note: This was originally intended for 
the Pennsylvania CoCoFest hosted by 
Ron Bull. Unfortunately. I never got 
there! Reprinted as originally typed. 

Why? 

I guess we need a purpose state- 
ment. The theory is, modem comput- 
ers contain CPU's that far surpass their 
users needs. But limited to One True 
Serial Processor, these machines of- 
ten leave their user staring at a hour- 
glass or piling work to the side until 
the 'right program' is loaded. Even with 
it in que, the amount of work that can 
be paralleled is small. 

This situation isnl likely to change 
as long as the only people capable of 
experimenting with the technology are 
those needing to protect next quarters 
net. but a modem CPU is just too fast 
and compact to play with. With the 
CoCo. we have hardware that's old 
enough, slow enough, and 9/10ths of 
the needed opsys available at close to 
free. 

At the time of the last Chicago 
CoCoFest. we had quite a talk on the 
CoCo4 project. Lots of good ideas 
where tossed around, but response on 
the mail list has been.... less than as- 
tounding. I think we needed a 2nd hour 
just to organize the project! 

The report from Milwaukee- 
Project B (I think it was B) was a 
GIME emulator running on a larger 
CPU. Some specs tossed about at the 
fest- we'd probably need a CPU-32 
core to avoid the nastiness of even 
word boundaries, and speed/sync 
would be a problem- nothing too earth 
shattering there. Cart has done some 
additional work since the fest. but he's 
got the IDE project to sweat over. Not 
being familiar with 68K code or the 
chips true grit, I'm eageriy awaiting 
news from PennFest. Feel free to step 
up. 

Project A was a co-CPU I/O board, 
designed to unload the mothertx)ard 
itself from the cycles needed to emu- 
late a keyt)oard with PIA, mouse inter- 
face with software timer, and the like. 
Another worthwhile project but again, 
no feedback. I think we've got the logi- 
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cai conclusion of that klea below... and 
one that can make good use of exist- 
ing designs. I'm hoping if anyone builds 
a true PA they'll let us steal the de- 
tails! But before that, something I've 
got data on, Project C. 

IRQ Controller 

My first hardware project has been 
the IRQ controller. To recap, the idea 
is to have each IRQ driven device pro- 
vkle two datum- the nonmal CART IRQ 
as an alert (also acting to compatible 
existing IRQ-poll software) and an ad- 
ditional discrete byte that describes 
the source of the interrupt. It should 
be relatively simple to cobble OS-9 to 
read the hardware provided ident byte 
rather than go through it's polling rou- 
tine- a substantial speed increase. 

The fine points- first, everything ex- 
cept the clock would leave a telltale 
byte in the IRQ register. In other words, 
if a CART is received and the register 
is 0. you've just gotten a clock IRQ. 
Second, the register is cleared on read- 
ing, so we could probably cheat a little 
bit- instead of ignoring IRQ during an 
IRQ service, check for nonzero IRQ 
buffer before returning to nonmal pro- 
cessing. This would catch one extra of 
anything but clock, and cost cycles 
in mid-routine. We could possibly FIFO 
the IRQ register, and adopt a better 
late than never IRQ scheme. In any 
case, this device should be installable 
and useful on a CoCo3. It will be an 
absolute requirement on the CoCo4, 
due to the raw number of IRQ that will 
be generated. 

Moving 4 ward. 

My next idea is to just start some- 
thing and see who joins in. The follow- 
ing is a general theme for a true 
'CoCo4' that could amount to more that 
stirring through the ashes for another 
spark. Consider this a request for com- 
ments. What I'd like to do Is solicit 
everyone's ideas, publish another 
RFC, etc.. until we end up with a real 
specification. Not a wish list- we know 
VGA graphics and 3 Gig IDE drives 
are nice. What we need is a service 
manual. Soft and hard ware problems 
can be studied In reference to a known 



spec, which will be changed to solve 
the problems... once everybody's 
happy (famous last words) we'll build 
it. I've got way too many potential 
specs to list here, so expect a quick 
gloss over the top and a big follow-up 
article. 

MultlCoCo 

Once we have a usable CPU/CPU 
buss the rest will come. I propose a 
box that accepts single CPU 6x09 
cards. The builder writes the code to 
make said 6x09 do anything, either as 
OS-9 code or stand-alone assembler, 
adds the needed hardware and plugs 
it into the box, which helpfully provides 
OS-9 system services (scheduling, file 
handling, etc.). This woukl combine the 
ease of programming and attaching 
devices to a CoCo2 with the manage- 
ment skills of OS-9. 

Design for the main board (sysCPU) 
has been purposely left for last. In the 
eariy stages, we can perhaps get away 
with a hacked CoCo as master CPU, 
but of course this will change as we 
determine what's needed. Anticipate a 
16 bit (RAM buss sized) CPU to CPU 
buss. 

A generic primary expansion unit 
(appCPU) might be a single 6x09, PIA. 
and 2 64 K banks of dram. Within the 
CPU's 128K, the ram is remappable 
(^remotely' by syscall to sysCPU) 
though of course each complete 128K 
segment appears Immobile to OS-9. 
The *bank switch' bit is read/writable 
by both CPUs and appCPU has 4 ba- 
sic states- 

1) running map A code 

2) running map B code 

3) HALTed pending system access 
(Both task halted, read DAT for 

pending request) 

4) tK)th maps busy 

The interCPU buss will be tristated for 
any bank the appCPU is using. OS-9 
could override this by halting the re- 
mote CPU and forcing state 3 (danger 
to app). 

Such a card has two uses- it can 
drive a bit of hardware via PIA, or it 
can take some code load off of the 
main CPU. The OS-9 code loaded into 
this board could be: 



mapA: 

1) shelldrv 

2) shell or sh09 

3) application modules. 

4) Data (Could also use mapB- 
see sh09) 

mapB: 

1) grfdrv/vgadrv 

2) screen 

1)moreOS-9/PIAdrv 
2) OS-9 data 

1) 6x09 assy (non OS-9) 

2) data swap to OS-9 

The Idea is you have one 64K pro- 
cess space, and one 64K map to do 
with as you will- free of the nomial 
scheduling constraints imposed by OS- 
9 (This scheme begs for a 51 2K ver- 
sion). An OS-9 task module controls 
the timing and signals for the *alien' 
task map. 

OS-9 on the daughterboard 

Shelldrv's main task is to pretend to 
be OS-9 to the application process. It 
needs to intercept anything a nonnal 
shell would send the system and halt 
the app CPU after pushing the CPU 
state- once restarted, it has to poke the 
app CPU into whatever state OS-9 re- 
turned (ram changes already done via 
dual port) and continue. Underthis, one 
could use shell to run normal OS-9 
code, using the main opsys i/o and 
scheduling. 

To implement non-OS-9 pages, we'd 
need a shell replacement capable of 
loading a code block into the alternate 
task map (or picking up the ROM) and 
riding head on it from the OS-9 side. 
In this document, it's called sh09. Sh09 
would also need to manage (OS-9ify) 
the immobile data blocks used in the 
alternate map. 

Basically, any system access to 
mapB would be under sh09's control 
leaving it outside the nonmal flow of 
OS-9. Sh09 would have to define the 
percentage of time it's particular 
appCPU spent running the foreign 
code, catch local IRQ before they get 
to shelldrv and OS-9- and pretend it's 
sleeping part of the time. 

The foreign code has a couple of 
ways to interface. First, it can simply 
write to the data area and let sh09 find 



it (and the reverse). It could also use 
the local IRQ system to run the (OS-9/ 
sh09) IRQ handler for time critical stuff. 
We'll need some heavy systems pro- 
gramming dudes to ponder on the OS- 
9/sh09/assembly details. 

OS-9 on the motherboard 

The task switching routine has to be 
changed. Until it mns out of appCPU's, 
OS-9 wont be spending any CPU time 
mnning mainline process code, instead 
there is going to be a wash of syscall 
requests. The scheduler will have to 
go by time in syscall rather than ticks 
per timeslice. Just doing it will be a 
task- when a syscall or other IRQ 
comes in, the system has to save It- 
self and the entire sysCPU state, load 
the whole appCPU state, page in the 
remote RAM, finally run the code and 
get back. This needs to be a terribly 
efficient bit of code, much of the 
system's time will be spent here. Alan 
(Dekok... of Nitro fame)? 

The ram DAT has to understand it's 
pool and the remote, semi-fixed ad- 
dress blocks of the app CPUs. Sh09 
can handle the non-OS-9 code, but the 
OS-9 side is itself sort of immobile. 
How to tell OS-9 a process sometimes 
has to load in the range aaaOOOO- 
aaaFFFF? (Also, it's data is always at 
a static location). There also has to be 
a way to page local and remote RAM 
around quickly so process can be 
swapped among the various CPU's 
RAM areas. Even disk data would be 
coming in this way! Pipes need to be 
beefed up to use the fast swapper for 
interCPU pipes. 

And if that's not enough, redirection 
has to be expanded to include CPUs 
as well as devices- and we need the 
companion Xprocs to identify which 
CPU a task is on. 

Possible Initial Card E)esigns: 

Smart DMA type hard/floppy 

disk controller 

Same thing in a SCSI controller 

Smart VGA card (also emulate 

GIME/grfdrv res) 

Multiport card for "other i/o'- stack the 

keyboard controllers and printer 

ports on one CPU 

'Mega ports' like a 16550 with built 

in PPP/slip 

Rack o' CPU (perhaps a half dozen 

6x09'swithRAM. nol/O) 



Multiple Math co-proc (pertiaps in the 
rack 0' with the MRola math ROM) 

Main System CPU- 
There is a major choice here- per- 
haps 2 competing systems. The first 
option is to capture 'current' (as in, not 
forgotten yet) Lvl2 knowledge in a 6x09 
system controller. If the video is moved 
to an app, one of the traditional 6x09 
problems (small, slow gfx) might be 
solved... with a 6x09! 

The second option is to use a 68K. 
Lots more ommph at the base and we 
could use a VGA card. The problem 
being OS-9 68K is harder to come by 
and hasnt been hacked as much. 

So the two sysCPU sections are: 

6809: There's no reason why a CoCo 
couldnl serve as the development en- 
gine- in fact, there are reasons to do 
so. During testing, a few known work- 
ing lyo systems can be handy, and bits 
of the motherboard can be written out 
of the opsys as they t>ecome ot>solete. 
As a product, the add to CoCo con- 
cept means a system can be tx}ught 
one card at a time. The user could 
stack 12 CPUs on the CoCos built in 1/ 
O, or let it's single CPU run free thanks 
to the smart drive controller and i/o 
board. Or anyplace between. Eventu- 
ally, a 6x09 motherix>ard of CPU. ram, 
monster DAT, and not much else could 
be developed. 

68xxx: OSK emulating OS-9? Or 
6x09s passing OSK style calls? If shell 
and shldrv are rewritten to 'look' OSK. 
we might as well go right to the multi- 
PPC engine and look for investors;-) 
If they appear OS9/6809, CoCo pro- 
grams would be compatible.... 

More later! 

Rick Ulland 

CoNect and ^operating system 9' 

1629 South 61st Street 

West AllisWI 53214 

pulland@omnifest.usm.edu 
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Zen of Color Computer Programming 

Interrupts and sound 



Chet Simpson 



A Little Recap. 

If you thought something was missing 
from the last issue, you just might be right 
Yes, I missed the deadline. During the time 
I needed to get the article to Frank, I was 
busy relocating from Des Moines, Iowa 
(where I worked for Microware in the MPEG 
group) all the way back to the West coast to 
sunny California! I'm nowtotalty moved and 
have settled down into my job (which is still 
in the Interactive TV arena). I'm finding my- 
self more and more attracted to this state 
(even though 1 seem to have an allergic re- 
action to earth quakes, but doesn't every- 
body?), especially since I haven't seen a 
SINGLE drop of rain since I have been here. 

Remember, in the first article I mentioned 
a challenge that was issued by a friend of 
mine. That challenge was to create [for the 
CoCo III] a duplicate of the MM/1 game 
"Gold Runner 2000." Well, unfortunately, I 
lost the challenge, but by technicality only. 
Seems that my move coincided with the 
deadline of having the game •complete.'* 
But never mind that, you can seethe results 
of the game in its final release as Digger II: 
Retum of the Saint (that's a product plug by 
the way!). 

What about the good stuff. 

In the last article, I mention playing real- 
time digital music like those used by nifty 
music programs running under MS-DOS. 
By real time music, I mean that digitized 
samples of musical instilments are played 
back with the various notes and sound ef- 
fects computed while the samples are be- 
ing played back.. Almost everyone that I 
have talked to about this said tiiat it was 
impossible to do. Until John Kowalski re- 
leased his CoCo III MOD player Unfortu- 
nately, doing all of those calculations to get 
the correct musical notes is very taxing on 
the CPU and leaves IrtUe time to do anything 
else. Because of this. I started looking at al- 
ternative ways to accomplish the same ef- 
fect but without using a ti-emendous amou nt 
of CPU time. The following starts off a 3 part 
series on how to get up to 4 voices real time 
digital music and still have at least HALF of 
the CPU left over. 

A little background. 

MODule files originated on tiie Commo- 
dore Amiga, tt allowed tiie Amiga to play 
back digital music in 4 distinct voices with- 
out any special sound hardware other than 
a Digital to Analog Converter (DAC). 

The original MOD files were made up of 
several parts; a simple header, instrument 
samples (up to 16), "pattern" data and a list 
of what order to play the 'patterns" at (al- 
lowing patterns to be reused). The most 
important part of a MOD file is the pattern 
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data as it described which sound sample 
and note to play it at for each voice. A de- 
coded MOD file might look something like 
this: 

Sample 1 : Snare drum 
Sample 2: Bass Drum 
Sample 3: Flute 
Sample 4: Symbol 



Pattern Data 


: 




(Displayed as sample: note/octave for all 


voices) 








Voice 1 1 

J. 


Voice 2 < 


1] 1 


C3 1 


3 


D1 < 


2] .. 


1 


3 


> 


3] 2 


C3 1 


A4 < 


4] .. 
5] 1 


1 
C3 1 


3 


> 

D4 < 


6] .. 
7]4 


1 
C3 1 


3 


> 

E3 < 


8] .. 


... 1 




1 



For now, lets look at vok:e 1 . The first note 
in the pattem plays sample number 1 (the 
snare drum) as note C in octave 3. If you 
look at the notes in most MOD players, you 
will find that this is a very common occur- 
rence, especially with rhyttim (drum) tracks. 
This is because most samples are recorded 
as a C note (no not a $1 00 bill) in octave 3, 
also known as Middle-C. This allows the 
samples to be "transposed" or changed 
into other notes and octaves in a known 
manner to the composer Keep in mind that 
It is not a requirement that the samples be 
recorded in Middle-C. You music butfs out 
there may have already noticed that there is 
no specification for the duration of the note. 
Line 2 signifies that the note does not 
change and therefore continues to play un- 
til the end of the sample. If the end of the 
sample is reached, nothing is played until a 
new sample is specified. 

But what about the CoCo you ask. 

During the final development stages of 
Digger II. 1 wanted to add something really 
special to it using the little but of memory 
that I had left over. I started to look at MOD 
type files (mainly because 1 have several 
megabytes of samples), but wondered if it 
would be done in a fast efficient way. So 1 
wrote a small program that really ripped into 
the MOD file, retrieved the size of each 
sample used along with how many notes 
and octaves it was played at I was quite 
amazed at how litde some of the small to 
medium sized MODS utilized the capabili- 
ties of tiie MOD players. While some of the 
smaller ones only used 1 00k, quite a few of 
the medium sized ones only needed 250k 



to 300k of total memory. This of course does 
not take into account many of the special 
effects (such as volume changes and Vi- 
brato) that a MOD can do. Needless to say, 
this got me very excited! My (then original) 
goal was to push out 2 voice real-time digi- 
tal music but ended up being 4 (but 6 is 
possible). 

Using the Timer FIRQ to play sound at 8 
kiiohertz. 

The best part about playing back sound 
on tiie CoCo 11! is that we can use tiie timer 
interrupt of the GIME chip to give us a con- 
sistent playback rate. You see, the GIME 
chip allows you to specify that an interrupt 
will occur within a specific amount of time. 
This can be done on either the IRQ or the 
FIRQ (Fast IRQ). Since we don't want to 
use a whole lot of CPU time, we will use the 
FIRQ, t)ecause unlike the nomnal IRQ, the 
FIRQ does not save the state of all registers 
which makes it FAST. What makes the 
GIME even nicer is that it automatically re- 
starts the timer after the interrupt has been 
acknowledged. 

In order to make the GIME chip send us 
an intenupt all we need to do the following 
(See Listing 1): 

1 . First we want to make sure that the 
FIRQ vector points to our FIRQ handler 
routine. If an FIRQ happens and the vector 
points to nowhere, tiie machine might crash. 

2. Nonnally, both the IRQ and FIRQ are 
generated the same way they are in the 
CoCo II in order to keep compatibility with 
older software. So the first tiling we need to 
do is tell the GIME we want to use its FIRQ 
mode. We do this by setting the FIRQ en- 
able bit which is bit 4 ($1 0) of ttie GIME INIT 
register ($ff90). 

3. Next, tell the GIME which event to trig- 
ger an FIRQ on [The GIME supports trig- 
gering an FIRQ for the keytK)ard, serial port 
and others hardware]. Since we want a 
timer interrupt, this is done by setting bit 5 
($10) at of tiie GIME FIRQ Enable register 
($ff93). 

4. Before we do anything else, we need 
to make sure that we receive an FIRQ at 
the correct time. So we first select the tim- 
ing mettiod (70ns) by setting bit 5 ($20) of 
the GlMEs 1NIT1 register ($ffgi) and ttien 
by setting tiie time internal to trigger an FIRQ. 
Rememt)er that the timer automatically re- 
starts when the MSB (Most significant byte) 
of the timer value is set 

5. The final part of the initialization that 
needs to be done is to tiigger tiie GIME to 
start sending us interrupts. To do tills, we 
simply read the value of the GlMEs FIRQ 
enable register ($ff93). Of course, we can 
also do any number of tilings between tiiose 
steps, which our demo code does in order 



to turn the sound on. 

Afl that Is left is to actually PU\Y the sound. 
Since our interrupt routine gets called 
around 8000 times per second, we want it 
to be as fast as possible. This is done with a 
litde optimization and the use of self modify- 
ing code. Don't worry, it only changes a 
couple of address and data bytes, none of 
the code actually changes. Since this is a 
very short routine, we'll step through it (It is 
also include at the end of the article as List- 
ing 2). 

How the sound is played. 

The sound routine is very simple. It starts 
playing at address $8000, Every time It plays 
256 bytes (1 page), It decrements a counter 
to help it keep track of where in the buffer it 
is. Once It has played 32 pages (8k), it starts 
playing at location $8000 again. 

Since the FIRQ hardware of the 6809 
does not save the states of the registers (with 
the exception of CC and PC) we need to 
save the registers that we do use. Thank- 
fully we only use register A. This is stored 
into the routine itself so that we can do an 
immediate load of the value t)ack into A. 
This Is much faster than doing a PSHS/ 
PULSoftheregister 

sirqrt 

sta smc+1 *saveACCA 

The next thing we do is get a byte from 
our sample buffer and send it out the sound 
port 

soffet 

Ida $8000 * get sound byte 
sta P1A1 * send sound out 

Now we get back to the self modifying 
code which is a littie bit tricky. When we get 
the byte from the sound buffer, we don't use 
any indirect addressing. If we did, we'd be 
wasting some CPU cycles. To get around 
this, we use extended addressing. But since 
we have to increment that address. First we 
increment the LSB of the address. When 
the LSB reaches 255, the next time it is 
incremented it goes back to zero. This is 
handy in that both a flag has been set in CC 
register and we have just played . 

inc soffst+2 

• increment LSB of offset 
bne endit 

* no overflow. Reset FIRQ 
and retum 

Since we have just played exactly 1 page, 
we now do 2 things, the first is increment 
the MSB of the address. This keeps us from 
playing the same 256 bytes all of the time. 
The next thing we do Is decrement our page 
counter. If this reaches 0, we know we are 
at the end of the sample buffer and we need 
to reset both the page counter (back to 32) 
and the address (back to $8000). When we 
reset the sample address back to $8000, 
you'll notice that only the MSB of the ad- 
dress is set ($80), this is because the LSB 
is already at $0 (convenient huh). 

inc soffst+1 



* increment MSB of offset 
bne endit * No 
dec count 

* Are we done playing 8k block? 
bne endit *No 

Ida #$20 * Get new count value 
sta count * set it 
Ida #$80 

* Get MSB of sample address 
sta soffst+1 * set it 

Next we need to reset the interrupt flag 
and do other cleanup. To reset the inter- 
rupt, ait we need to do it read the value of 
the GIMEs FIRQ enable register. We could 
use TST but it is 1 cyde longer than LDA. 
Next we restore register A back to its origi- 
nal value. Remember the first line of the 
FIRQ handler stored it here. The we do an 
RTI (Retum from Interupt). Do NOT use 
RTS! 

endit 

Ida FIRQENR * reset FIRQ status 

smc 

Ida #$ff * Restore ACCA 

rti * retum 

Caveats. 

Keep in mind that this is not a complete 
set of routines for playing back sound. It only 
plays a sound sample from 1 area of 
memory. When using these routines make 
sure that you have the IRQ disabled (keep 
the FIRQ enat)led or it won't work). This will 
keep the IRQ routine in DECS from crash- 
ing the machine. 

Contact information. 

Yes. I have moved! Fan mail, chocolates 
(packed in dry ice please), mail bomt>s, etc. 
can now be sent to: 

Chet Simpson 

5525 Canoga Ave, #320 

Woodland Hills, Ca 91367 

Or if you prefer SPAM: 

medialink@delphi.com 

Next time. 

In the next issue we will combine tx)th 
the IRQ and the FIRQ for playing back more 
than one sound and we'll get started on what 
we need in order to play real-time digital mu- 
sic on our "slow" 2mhz CoCo. 

Listing 1 (Initialize GIME and Sound): 

PlAOequ $ffOO 

DAPORT equ $fT20 

P1A1 equ $fr20 

INIT equ $fY90 * Initializatkm register 

INIT1 equ $(f91 * Initialization register 1 

IRQEN equ $ff92 * Inteniipt request 

enable register (IRQ) 

FIRQEN equ $fr93 * FIRQ enable register 

TIMSB equ $ff94 * Timer MSB 

TILSB equ $ff95 * Timer LSB 



TMR equ $20 * Timer FIRQ enable 

pshs cc,x,d * save cc registers 
orcc #$50 * Disable interrupts 

* Set up hardware FIRQ vector 

kla #$7e ^ use JMP operande 
Wx #firqrt ' point to FIRQ routine 
sta FRQVEC * set the FIRQ vector 
sb< FRQVEC-H * Set FIRQ handler 

* Set up GIM E to use the F IRQ 

Ida #$4c+FEN * Enable GIME FIRQ 

sta INITO *setrt 

Ma #TINS * select 70ns 

sta tNm * set Init register 

Ida #TMR * select timer irq 

sta FIRQEN * use FIRQ 

Idd #470 * Get timer (dk) count down 

* value 
stb TILSB * set timer isb 
sta TIMSB * set timer msb and start 

•counter 

* Reset values for FIRQ routine 

kia #$20 * Play 32 256 byte pages 
sta count * set it 
Idd #$8000 * Start playing at $8000 
std soffst+l * set It 

* Turn on 6 bit sound 

kla PIAO+I * select 8our)d out 

anda#$f7 *resetMUXbit 

sta PIAO+1 • set it 

Ida PIAO+3 * select sound out 

anda #$f7 * reset MUX k>it 

sta PIAO+3 * set It 

kla PIA1+3 *GetPIA 

ora #$08 * select 6b(t sound 

sta PIA1+3 * set it 

clr $fM * Reset MMU to play from 

kla FIRQEN * reset FIRQ 

puis dp(,cc,pc * retum 

Listing 2 (Handle FIRQ): 

count fcb $00 

firqrt sta smc+1 * save ACCA 

sofTst Ma $8000 * get sound byte 

sta PIA1 " send sound out 

\nc soffst-(-2 * increment LSB of offset 

bne endit * No overflew 

inc soffst+l * increment MSB of offset 

dec count * Are we dorie playing t)k)ck? 

bne endit * No 

inc $ffa4 * Increment 

kla #$20 * Get newcount value; 

sta count * set it 
endit kla FIRQENR * reset FIRQ status 
smc kla #$ff * Restore ACCA 

rtl *retum 



FEN equ $10 
TINS equ $20 



* GIME FIRQ enat)le 

* Tirrwr input 
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Transfer .DSK Files! 

Use CoCo emulator ,DSK files on your CoCo or the emulator! 



Bob Devries 



RSDSK and OS9DSK are two pro- 
grams I wrote recently in response to 
messages on the COCO list on 
PRINCETON (coco-list® 

princeton.edu). There had been talk 
of the disk image files (.DSK) that 
are created for Jeff Vavasour's COCO 
emulator. These files are an exact im- 
age of a Color Computer disk, track- 
by-track, sector-by-sector For the Disk 
Extended Basic image files, they are 
161280 bytes long, for 35 track, 18 
sectors pertrack disk images. The disk 
images used under OS-9 with the emu- 
lator may, of course, be any size. 

These files are now being uploaded 
to COCO FTP sites like 
0S9ARCHIVE.RTSI.COM. Problem 
is, they are only useful to people who 
have an IBM PC or clone. People who 
only have a COCO and/or one of the 
OS-9/68000 based computers such as 
the MM/1 , could not get at the infor- 
mation stored in those files. Imagine 
having a computer disk, but not hav- 
ing the OS that it was created on! 

So, being the sort of person I am, 
I decided to see if I could write a pro- 
gram to 'read' the image files under 
OS-9. I started off programming it on 
my MM/1, and when I had it working 
to my satisfaction there, I did the nec- 
essary modifications to make it com- 
pile under BOTH OS-9/6809 and OS- 
9/68000. 

I started with the DECB image files, 
which I thought would be the easiest, 
since there's only a single directory, 
with a maximum length of 16 sectors 
(yes, I know it should t}e 9, but I wanted 
to allow for disks larger than the stan- 
dard 35 tracks), 128 entries maximum. 
Also, I had many times written BASIC 
programs to read the directory from a 
DECB disk. 

It turned out to be easier to rewrite 
from scratch, than to *cop/ the BASIC 
program. Of course, it was to be writ- 
ten in C, which is what I write in most. 

About a day and a half later, I had a 
program which would do a directory of 
the disk, and another day later I had 
the program completed, with capabil- 
ity to do a directory, copy a single file 
FROM the image file, and make a pro- 



cedure (script) to get all the files from 
the image file. I didn't then, and still 
have no intention to write one to copy 
TO the image file. 

Usage of the RSDSK program: 
RSDSK -dir filename.DSK 

or 
RSDSK -get filename.DSK 
DECB.filename OS9.filename 

or 
RSDSK -proc filename.DSK 

The first example will produce a 
directory of the emulator image file 
^filename.DSK'. Note the full filename 
is necessary, including the '.DSK'. The 
second example will copy the file 
called DECB.filename from the emu- 
lator image file Filename.DSK' to the 
OS-9 pathname *OS9.filename'. The 
third example is something I thought 
should have been done by the author 
of the program 'RSDOS', which reads 
COCO DECB disks under OS-9. It 
produces a procedure file which will 
copy all the files from the emulator 
image file "filename.DSK', much like 
the 'dsave' program does under OS- 
9. This procedure can then be edited, 
or executed as a script file, or piped to 
shell from the same command line. 

Having done all that for DECB emu- 
lator image files, I was left with noth- 
ing to read OS-9 emulator files. So that 
was the next challenge. 

It was both much easier, and much 
harder. Easier because the directory 
structures and other code is already in 
place to use in the C compiler. Harder 
t)ecause OS-9 has a tree-like directory 
structure. To transverse down the di- 
rectory tree required Yecursion', which 
was entirely new to me. 

Anyway, a few days later, I had a 
working program, and promptly up- 
loaded it to the FTP site, only to be 
tripped up by Jeff Vavasour himself, 
with an example disk image file that 
was bundled with the new version of 
the CoCo3 emulator It had a set of 
conditions that I had not allowed for, 
and my program promptly went hay- 
wire. It took me long hours to find the 
problem. 

The syntax of the OS9DSK program 



is much the same as the RSDSK one, 
with the addition of a 'directory' argu- 
ment. 

OS9DSK -dir filename.DSK 
dirpathname 

or 

OS9DSK -get filename.DSK 
imagepathname os9pathname 
or 

OS9DSK -proc filename.DSK 
dirpathname 

In the examples, 'diipathname' is the 
optional pathname to the directory re- 
quired (like CMOS or USR/VED/ 
CMOS). In example one, the output is 
much like the dire (or dir -e) command. 
In example two, the 'imagepathname' 
is the pathname (as shown by the - 
dir' command) of the wanted file in the 
emulator disk image file, and 
os9pathname is the place where you 
want the file copied to. In example 
three, a procedure file is created (again 
like the 'dsave' command). A starting 
directory can optionally be used. All 
subdirectories encountered are de- 
scended into. This output can be ed- 
ited, run as a shell script, or piped to 
shell. 

Where do you get it? 

Currently the files are on the 
OS9ARCHIVE.RTSLCOM FTP site in 
the directory VOS9/incoming/coco" 
and VOS9/incoming/osk". They are 
called *rsdsk.lzh' and *os9dsk.lzh'. The 
programs are freely distributable, and 
source code is provkled for you to leam 
from. It is NOT well commented, but 
if you need help understanding 
them, or have any bug reports, I'm 
available on the Internet at: 

bde vries@gil .com . au 

(Australia) 



NOTE: Copies of 
these programs are 
available on disk by 
sending $5 for a 
shipping/handling/ 
copy fee to FARNA 
Systems. 
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MawkSoft 



28456 S.R. 2, New Carlisle, IN 46552 

2 19-654-7080 eves & ends MO, Check, COD; US Funds 

Shipping included for US, Canada, & Mexico 

MM/1 Products (OS-9/68000) 

C1>F $50,00 - CD-ROM File Manager! Uolodc a wealth of files on CD with the MM/1 ! Read most text and 
sonic graphics fixxn MS-DOS type CDs, 

VCDP $50.00 - New Virtual CD Player allows you to play audio CDs on your MM/1 ! Graphical interface 
emulates a physical CD player. Requires SCSI interface and NEC CD-ROM drive. 

KIXXIC SiaOO - Optional Cuckoo on the hour and half hour! ! Continuously displays the digital t^ 
dale on the /term screen or on all open screens. Requires I/O board, I/O cable, audio cable, and speakers. 

WAVES vr I^ $30.00 - Now supports 8SVX and WAV files. Allows you to save and play all or any part of 
a sound file. Merge files or split into pieces. Record, edit, and save files; change playback/record speed. 
Convert mono to stereo and vice-ver«a! Record and play requires I/O board, cable, and audio equipment 

MM/1 SOUND CABLE $10.00 - Connects MM/1 sound port to stereo equipment for recording and play- 
back. 

GNOP $5.00 - Award winning version of PONG(tm) exclusively for the MM/1. You'll go crazytrying to 
beat the clock and keep that @#$%& hall in line! Professional pongists everywhere swear by (at) it! Requires 
MM/1, mouse, and lots of patience. 

CoCo Products (DECB) 

HOME CX>NTROL $20.00 - Put your old TRS-80 Color Computer Plug n' Power controller back on the 
job with your CoCo3! Control up to 256 modules, 99 events! Compatible with X^IO modules. 

HI & LO RES JOYSTICK ADAPTER $27.00 - Tandy Hi-Res adapter or no adapter at the fli<^ of a 
switch! No more plug and unplugging of the joystick! 

KEYBOARD CABLE $2&00 - Five foot extender cable for CoCo 2 and 3. Custom lengths avaihible. 

MYDOS $1S00 - Customizable, EPROMable DECB enhancement The commands and options Tandy left 
out! Supports double sided and 40 track drivea, 6ms disk access, set CMP or RGB palettes on power-up, 
coine up in any screen size. Speech and Sound Cartridlge support, poiiit and cUdc mouse directory, and MORE 
OPTIONS than you can shake a stick at! Requires CoCoS and DECB 2. 1. 

DOMINATION $1S.00 - Muhi-Player strategy game. Battle other players armies to take control of the 
planet Play on a hi-res map. Beconu a Planet-Lord today! Requires CoCo3, disk drive, and joystick or 



SMALL GRAFX ETC. \ 

"Y" and "TRT cables. Special 40 pin male/female end connectors, 

priced EACH CONNECTOR - $6.50 

Rainbow 40 wire ribbon cable, per foot - $1 .00 

Hitachi 63B09E CPU and socket - $13.00 

MPI Upgrades for aU small MPIs (sateUite board) - $10.00 

Serial to Parallel Convenor with 64K buffer 

and external power supply- NOW ONLY $28.00!!! 

Serial to Parallel Converter (no buflFer) 

and external power supply - ONLY $18.00!!! 

2400 baud Hayes compatible external modems - $15.00 

Serial to Parallel Converter or 

Modem cable (4 pin to 25 pin) - $5.00 

ADD $3.00 S&H FOR FIRST ITEM, $1.00 EACH ADDITIONAL ITEM 

SERVICE, PARTS, & HARD TO FIND SOFTWARE WITH COMPLETE 
DOCUMENTATION AVAILABLE. INKS & REFILL KITS FOR CGP-220, 
CANON, & HP INK JET PRINTERS, RIBBONS & vr, 6 EPROM FOR CGP- 
220 PRINTER (BOLD MODE), CUSTOM COLOR PRINTING. 



^ 



Terry Laraway 

41 N.W. Doncee Drive 

Bremerton, WA 98311 

360-692-5374 



The BlackHawk MM/lb 

Based on the ATS 06 board from 
Kreider Electronics. Features built 
into the motherboard include: 

16 bit PC/AT I/O bus with five slots 
MC68306 CPU at 16.67MH2 
512K to 16MB of RAM Avith 

30 pin SIMMs (4 sockets) 
IDE Hard Drive Interface (2 drives) 
360K- 1.44MB Floppy Drive 

Interface (2 drives) 
Two 16 byte fast serial ports 

(uptoUSKbaud) 
Bi-directional parallel printer port 
Real-time clock 
PC/ AT keyboard interface 
Standard PC/AT power connector 
Baby AT size - fits standard PC case 
BASIC (resembles Microsoft 

BASIC) 
MGR Graphical Windowing Envi- 
ronment with foil documentation 
"Personal" OS-9/68000 Vr 3.0 

(Industrial with RBF) 
Drivers for Tseng W32i and 

Trident 8900 VGA cards 
Drivers for Future Domain 1 680 and 

Adaptec AAHlSxx SCSI cards 
OS-9/68000 Vr 2.4 with Microware 
C 3.2, Assembler, MW Basic (like 
Basic09), MW Debug, MW Pro- 
grammers Toolkit 
UUCP from Bon Billson 
Ghostscript (software PostScript 

interpreter) 
Many other utilities and tools 

Prices start at $400! 

(motherboard. 

Personal OSK, & MGR only) 




BlackHawk 
Enterprises, Inc. 

s756GauseBlvd#29 

SlideU, LA 70458 

E-mail: nimitz@stolY.com 
••••••••••••••••••••• 
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friends to 
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the only 

magasiiio that 

still supports 

tiiO 

Tandy Color 
C!oinputor».« 

Thomoro 
people iftfho 
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G-WindOWS Error Steve Adams 

Mixing different versions of G-Windows and G-View 



Question: 'We're developing a G- 
Windows app using G-View on a 
MVME162 box. The target is a 
eSSeO-based system running OS-9 
v3, 0. On ttie target we're running the 
newest version ofG-Windows (ed, 62 
if I recall correctly), but on the 
VME162 box we're compiling under 
G-Windows ecf. 54 (once again 

iiRay 

There is one discontinuity in the de- 
velopment of G-Windows. Except for 
this one problem that I had to work 
around, every change to G-Windows 
has been fully backward compatible. 

You cannot mix versions of G-Win- 
dows and G-View if they lie on oppo- 
site sides of the edition #62 bound- 
ary. 

Now an explanation of the cause 
of the discontinuity: With V 1 .2 of the 
OS9/68000 Ultra C compiler, Micro- 
ware changed the variable definitions 
in the cstart.r file. Variables like 
'ermo' are defined in cstarLr, and pre- 
viously were always in the same po- 
sition in a program's data space. This 
was important when using sub-rou- 
tine modules, because it gave them 
a way to access the 'ermo' variable. 
When I originally designed gadget 
subroutine modules, I followed ex- 
ample source code from Microware 



that relied on the variable definitions 
in cstart.r. 

The cstartr file with OSK Ultra C 
{VI .2 and later) has the 'ermo' and 
other variables declared in a differ- 
ent order, so the ermo variable ended 
up in a different location in the vari- 
able space. When gadgets thought 
they were writing to the *ermo' vari- 
able, they were really writing to a 
stack checking variable. This made 
programs quit randomly with a stack 
overflow error. There were probably 
other related problems as well. 

I couldn't very well ask Microware 
to take back all copies of their Ultra 
C compiler and change back to the 
old fonmat, so I had to change the 
gadget structure so gadgets would 
not reference these variables. I did 
put in a check so when incompatible 
programs and gadgets are used to- 
gether, they abort immediately rather 
than wait for a strange error later on. 
I apologize for not using a more de- 
scriptive error code, but there isn't 
one. 




SUKUXSI 



I would really like to run this as a regular column. What I am looking for is sources for hard to find and bargain items for CoCo, 68K, and general computer 
use. If you find a treasure trove of good, inexpensive parts, let me know! 

CoCo and MM/1 RGB Monitors! 

I think I have found a source for the great Magnavox 8CM515 monitors! These were badged as "Magnavox Professional RGB 
Monitor 80". They are 14" monitors with Analog RGB (for the CoCo 3, MM/1, and Amiga), digital RGB (for IBM/Clone CGA output) 
and combined and separate composite (combined for CoCo or VCR, separate for some Commodore models). I've used one of 
these for years, and they were highly recommended by Marty Goodman and other CoCo gurus. It Is possible these are the larger dot 
pitch Magnavox 8CM505, but at this price ($45!!) even It would be a great deal! All are used with a 90 day warranty. Shipping should 
run around $15. 



Computer Recyclers 

972-245-3008 
crecycleQairmail.net 



If you still haye a CoCo and an IBM compatible machine on your desk, here is a good solution., one monitor for 
both! These are refurbished NEC multisyncs that sync from 15 75-36KHz... low enough for the CoCo3 yet high 
enough for 1024x768 VGA graphics! $175 each. ~" ■ " " 



Pikul & Associates 

101 Glenfield Drive 

Festus, MO 63028 

314-937-0335 
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680x0 Series Performance Guide 

Tips and tricks for writing fast 68K code. 



Andrei hfloutchkine 



Once upon a time, 1 needed to develop 
a graphics library for an embedded project 
in 68K assembly. I remember how I 
couldn't find much hints on how to write 
fast 68000 code anywhere back then, so I 
decided to write down some tricks I (earned 
from my mistakes to spare someone else 
from making them. Most of these are 
faster/smaller alternatives to triviar imple- 
mentations of common tasks discovered 
in "Wait a minute. There is a better way to 
do this!" fashion. 

This guide applies to original 68000- 
based and CPU32 cores most common 
to embedded 68K systems. Everything in 
here could or could not be true for bigger 
68K processors and ColdFires. If you find 
something to add to this guide or any bugs 
or comments drop me a note at 

muchandr@csua.berkeleyedu 

The latest version of this file is avail- 
able at 

http://www.csua.berkeley.edu/ 
--muchandr/m68k 

The target audience is people already 
intimately familiar with 68000 instruction 
set It is not meant as an introduction. 

I. FUNCTION CALLS AND CONTROL 

1. If you are writing a function that has 
no local variables, don't create an empty 
stack frame. I mean skip that 'link An,#0'. 
Note that your stack will be one word 
shorter then. 

2. bsr is better than jsr. bsr.b/bcc.b is 
better than bsr.w/bcc.w, which is in turn 
better than bsr.l/bcc.l. Always try the short- 
est possible displacement first. This is 
because an 8"t)(t offset fits into branch in- 
struction, 16-bit uses an extension word 
and 32-b>(t uses two. Any instruction with 
unqualified size could be silently as- 
sembled into .w by default, which sucks 
for branches. Check your assembler's 
manual. I don't recommend leaving the 
size unqualified for any instruction that has 
more than one possible size. 

3. A combnnation of individual move's 
(not necessarily all of the same size) can 
be faster than a movem. Count the clocks. 
The breaking point is usually around 4-5 
on 68331. 

4. Nothing prevents you from having 
several entry points into the same proce- 
dure or having several rts' except for scom 
of structural programming minions. 

5. Ignore the procedure calling conven- 
tions inside your own code. Consider sav- 
ing registers you wish to preserve across 
a procedure call in unused address regis- 
tens. If you are working with words on a 
CPU32. alternating moves to memory vwth 



swaps is very fast too fc>ecause swaps have 
a large head. Effectively, you will be sav- 
ing every odd register in memory and ev- 
ery even one in upper word of itself: 

move.x Dn, memory 

swap Dm 

II. ADDRESSING 

1. 'addq.x #oflset, An' is better than 'lea 
offeet(An),An'. In all other cases try to use 
lea for address calculations over adds. 
Depending on which processor you have, 
lea will be at least the same speed as com- 
bination of adds and shifts for any address 
with nonzero ofiset Note that lea can be 
abused to perform a lot of math other than 
address calculation at once. 

2. Any operation on an address register 
affects the entire register regardless of the 
size of this operation. If you are finding 
yourself using something like 'adda.l 
#constant,An' you are probabty wrong and 
adda.w will do as good of a job. (only 
faster) 

III INSTRUCTION SET USE 

1. 68000 is not a load/store instruction 
set Leave the values used only once or 
twice in memory and access them directly 
by instruction doing arithmetc on it (i,e. 
there is no need to move them into regis- 
ters first) I imagine this is a common pit- 
fall for people with high-perfomnance mod- 
ern RISC CPU background. I repeatedly 
caught myself going through unnecessary 
trouble to avoid going to memory at any 
cost. People who mostly did 8-bit stack 
based assembly before are probable to 
make the opposite mistake and 
underutillze 68K's (mostly) orthogonal reg- 
ister set 

2. tstx is better than 'cmpi.x #0' or, god 
forbid, 'btsti #3r/'btstw #15rbtstb #7'. 

3. Use moveq instead of move where 
you can. It is easy to forget that moveq 
accepts a much larger range of numbers 
than addq/subq. 

4. On a CPU32, try to order your instruc- 
tions so that you follow instructions with 
an operand fetch to memory/trailing write 
immediately by dbcc's (head 6) or shifts/ 
rotates (head 4+) or swaps (head 4) or bit 
ops (head 2-4 on a register) or any instruc- 
tion with non-register source (head 3+) or 
short branches/exchanges (head 2) to 
maximize instruction overiap and utilize 
CPU32's mini-pipeline well. Consult the 
tables in section 8 of CPU32 reference 
manual for exact timings. 

5. You don't get to show off the xor trick- 
There is an exchange instruction. 

6. Don't forget that moves set the con- 



dition codes too, not only arithmetics, (i.e. 
no need to test something you just loaded). 
Any operations on address registers do not 
touch CC's however. 

7. On a CPU32, use the '68010 loop 
mode' for bulk transfers. To do so, set up 
a dbcc loop that branches back to the pre- 
vious instruction. Any single-word instruc- 
tion will do, but you probabty want 'move.x 
memory, memory* or 'move.x Rn, memory 
type thing. Complicated addressing modes 
will disat)le the loop mode, because they 
require extension word(s). Note that this 
includes the immediate mode an anything 
but 'quick' instructions. The loop mode is 
essentially an instruction cache 3 words 
(2 instructions) large. 

8. There is no reason why dbcc should 
always loop backward. Consider this piece 
of pseudocode: 

while(counter - -) 
if (counter even) 

dofoo 
else #odd 
do bar 
(This kind of logic would be very com- 
mon on a device that uses a graphics sub- 
system with 4-brt color depth) 

Mere you can eliminate constantly 
checking for a condition inside the loop by 
having code segments for foo and bar ter- 
minate with dbf s branching to the alter- 
nate segment like this: 
foo: 

dbf Dcounter,bar 
bar: 

dbf Dcounter.foo 

9. Use add.x Dn.Dn to do a multiply by 
2/lefl shift by one. Use add twice for x4/ 
left shift by 2. It is still faster than shifting 
this way unless you are on an original 
68000-based core and the data is long (.1). 

10. Often extend instructions can be 
used to clear upper bits of a register more 
efficiently than something like 'andi.x 
#mask,Dn'. Just make sure that bit 7,15 
or 31 (the sign bit) is always zero in the 
largest possible value you can have. 

11. Think of sec as of conditional move 
of -1. Followed by add/sub you can nicely 
add/subract 1 conditionally without any 
branching. 



continued on page 17 
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CoCo3 Extended Memory Secrets Part 3 

The FF9x Registers 



Herbert Enzman 



Now that you have some experience 
under your belt, It is time to ptay with some 
of the $FF9x registers. We can use Z-BUG 
to change values in these registers and 
see the results on the screen. I will WARN 
you now that when changing some of these 
registers, you will change WHERE and 
HOW the screen is displayed, and it will 
APPEAR that Z-BUG has crashed, but it 
Is still in control! You will just be TYPING 
BLIND, and will have type carefully when 
the screen goes bonkers. 

It took some time to compile this infor- 
mation because most of the $FF9x regis- 
ters are WRITE ONLY, and when reading 
them with Z-BUG, only $1B is returned. 
This made it difficult to find out WHAT 
value is NORMAL for that particular regis- 
ter. The tables in this tutorial will save you 
a lot of tedious work. 

The information presented here is NOT 
the last word on the subject, only a start 
TABLE 10 for example, only lists SOME 
information for $FF99 in text mode. Some 
values for $FF99 will just repeat what is 
already in the table, and some will display 
1 line into 2, because SECB is setup for 
the 80 column display at this time. There 
are times when several $FF9x registers 
have to be changed for certain display 
modes, as can be seen in TABLE 11. 

Why there are two tables for GFX is un- 
certain. $FF99 graphics modes will not be 
covered at this time, but will be in a future 
installment I won't waste space or time to 
cover information that has already been 
presented on the $FF9x registers; The 
scope of this tutorial is to cover WHAT 
VALUES to PLUG into them to get some 
USEFUL work. 

I'll start with $FF99 - text mode and then 
end with $FF9D /$FF9E, since these do 
the most work. TABLE 9 describes the 
other $FF9x registers; some of which will 



be covered in more detail in the GFX tuto- 
rial; plus some TEMPS used by SECB. 

The previous installment covered the 80 
column-attribute mode of the MMU. Now I 
will explain the NON-attribute text mode, 
something the service manual did not 
cover. By setting bit 1 (CRESO) of $FF99 
to a '0'. the MMU goes into the NON-at- 
tribute mode. This means that there is NO 
attribute byte sent to the screen, that ev- 
ery screen location is for characters, and 
you are limited to 2 colore. The palette reg- 
istere involved are $FFBO for background 
and $FFB1 for foreground. 

Another interesting feature of $FF99 is 
its ability to add extra screen lines either 
with or without attributes. TABLE 10 shows 
this information. For example: a value of 
$74 plugged into $FF99 will give you an 
80x28 screen with NO attributes. $7D will 
give you the same WITH attributes. 

One interesting thing about the 80x28 
screen, is that lines 25-28 will not scroll 
with the SECB screen routine. SECB 
knows (in its code), how many lines to 
scroll, so it ignores 25-28. To get them to 
scroll, you would have to change the # of 
screen lines that it scrolls in SECB's code, 
or use your own screen routine and scroll 
it But even if you don't, this non-scrolling 
can have some interesting uses! You could 
take advantage of this feature, and use it 
for IMPORTANT messages that you want 
to STAY on the screen. The same is true 
for the 80x25 screen, line 25 stays put 

LISTING 10 will demonstrate how to set 
up SECB to use, display, and scroll an 
80x28 screen. Type it in, assemble it into 
memory and run it from Z-BUG. Now, fill 
the screen with text and count the number 
of lines on the screen; and they should add 
up to 28 lines. See, there is nothing to it 
when you know how! Why didn't TANDY 
tell us how to do it??? 



TABLE - 


8 Block number VS. 


screen 


display offset (see text; 


1 


BLOCK 


FF9D 


9E 


BLOCK 


FF9D 


9E 


BLOOK 


FF9D 


9 


BLOOK 


FF9D 


9E 


00 


00 


00 


10 


40 


00 


20 


80 


00 


30 


00 


00 


01 


04 


00 


11 


44 


GO 


21 


84 


00 


31 


04 


00 


02 


08 


00 


12 


48 


00 


22 


88 


00 


32 


08 


00 


03 


OC 


00 


13 


40 


00 


23 


80 


00 


33 


00 


00 


04 


10 


00 


14 


50 


00 


24 


90 


00 


34 


DO 


00 


05 


14 


00 


15 


54 


00 


25 


94 


00 


35 


D4 


00 


06 


18 


00 


16 


58 


00 


26 


98 


00 


36 


D8 


00 


07 


.10 


00 


17 


50 


00 


27 


90 


00 


37 


DO 


00 


06 


20 


00 


18 


60 


00 


28 


AO 


00 


38 


EO 


00 


09 


24 


00 


19 


64 


00 


29 


A4 


00 


39 


E4 


00 


OA 


28 


00 


1A 


68 


00 


2A 


A8 


00 


3A 


E8 


00 


08 


20 


00 


IB 


60 


00 


2B 


AO 


00 


3B 


EO 


00 


00 


30 


00 


10 


70 


00 


20 


BO 


00 


30 


FO 


00 


OD 


34 


00 


ID 


74 


00 


2D 


B4 


00 


3D 


F4 


00 


OE 


38 


00 


IE 


78 


00 


2E 


B8 


00 


3E 


F8 


00 


OF 


30 


00 


IF 


70 


00 


2F 


BO 


00 


3F 


FO 


00 



TABLE 9 - other FF9x registers 

$FF90 MMU disabled = $CC 
MMUenat)led =$4C 

$FF91 00 for Task register - 
01 for Task register - 1 

$FF92 - $FF95 

Haven't gotten to these yet! 

$FF96 / 97 RESERVED - not used 

$FF98 USE - $03 for TEXT 

USE - $80 for GFX (M plane) 
More on this register during 
the GFX tutorial 

$FF99 SEE Tutorial text 

$FF9A BORDER register (color) 

$FF9B RESERVED - not used 

$FF9C SEE Tutorial text 

$FF9D/$FF9E 

$D800 = for 80 column text 
*** SEE Tutorial text 
$C000 = GFX screen (bit plane) 
GFX portion will be covered in 
GFX tutorial 

$FF9F $00 = NORMAL 

$80 = 128 column text screen 
(see text) 

not very usefull during graphics 
(see GFX text) 



Want to try out a 128 column screen??? 
Nothing to it!! Just type in LISTING 11, 
assemble It to memory, and run it from Z- 
BUG with 'GGO'. It is just a simple pro- 
gram to demonstrate how to set SECB for 
a 128 column screen. Just start typing any- 
thing to the screen, anything at all; a novel, 
a letter to the editor, anything. When the 
cursor gets to the far right side of the 
screen, you will notice that the screen will 
start to scroll horizontally. If you send a 
carriage return, or you get to the end of 
the 128 character line, the screen will jump 
back to the left margin. You can also move 
the screen horizontally using the <shift left 
an^ow> or <shift right arrow> keys. 

To set this mode, all we did was set BIT 
7 of $FF9F to 1 ($80), which is called the 
•horizontal Virtual Enable" bit. Then by 
incrementing $FF9F from $80 up (81, 82, 
83, etc.) we can move the screen left by 
one character space. Of course, we also 
had to change some of the code in SECB 
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to help it along with displaying this mode. 
Notice in the listing that we keep a RAM 
Image of $FF9R This is because $FF9F is 
a WRITE ONLY register If you try reading 
It, all you will get returned is $16'. One 
extra routine was added for SECB to use. 
It will cause the screen to reset to the left 
margin when SECB sends a C.R to the 
screen. I located it into SECB's copyright 
area, which is a nice large, unused area 
of memory for patches. The 128 screen 
demo just setup an intercept to use this 
e)(tra code at the start of the routine. The 
DEMO is fully commented, so you can 
modify it for other uses. 



TABLE 10 - 


TEXT table information for $FF99 1 


FF99 


line 


end 


screen 


with 


$FF9E note 


value 


adjust 


offset 


size 


attribute adjust 1 


$06 


$20 


$02FF 


32x24 


NO 


$08 


$04 


$28 


$03BF 


40x24 


NO 


$0A 


$10 


$40 


$05FF 


64x24 


NO 


$08 


$14 


$50 


$077F 


80x24 


NO 


$0A 


$1D 


$A0 


$OEFE 


80x24 


YES 


$14 (1) 


$28 


$20 


$031 F 


32x25 


NO 


$08 


$24 


$28 


$03E7 


40x25 


NO 


$0A 


$30 


$40 


$063F 


64x25 


NO 


$08 


$34 


$50 


$07CF 


80x25 


NO 


$0A 


$3D 


$A0 


$0F9E 


80x25 


YES 


$14 (2) 


$68 


$20 


$037F 


32x28 


NO 


$08 


$64 


$28 


$045F 


40x28 


NO 


$0A 


$70 


$40 


$06FF 


64x28 


NO 


$08 


$74 


$50 


$08BF 


80x28 


NO 


$0A 


$7D 


$A0 


$117E 


80x28 


YES 


$14 (3) 


NOTES: 










(1) NonDal 80 column screen 






(2) Line 25 does not scroll 






(3) Unes 25 - 28 do not scroll 






(4 


1 screen 


START = J 


SxOOO x 


= depends upon 1 




$FFAx register range that block $36 


is mapped 1 




into (see TEXT). 








(5 


) screen 


END = add 'END OFFSET to screen 




start for actual end 


, (lower right comer of screen) 1 


(6 


1 screen 


without attribute is 


2 color only. 1 




$FFBO 


= background $FFB1 = foreground 1 



The 'line adjust column in TABLE 10 is 
used to add to the cursor location so that 
the cursor can be moved up or down (it is 
the line length). The 'FF9E adjust" column 
is used to change where the MMU starts 
displaying the screen by 1 line (more on 
this later), so don't confuse the 2 columns. 
The 'end offset* column is used to calcu- 
late the end of the screen, depending on 
which tHock the screen is mapped into (re- 
member this from last time?). 

For exarriple: if the screen block ($36) 
is mapped into $FFA3 ($6000-$7FFF) and 
you chose $30 as the $FF99 value, then 
the screen would end at $6F9E, ($6000 + 
$0F9E = $6F9E). If you chose $7D, the 
screen would end at $717E ($6000 + 



$117E = $717E), etc.. 

The best way to see what is happening, 
is to experiment with some values plugged 
into $FF99. DISK EDTASM users should 
set up the 80 column screen by using LIST- 
ING 2; and E/A 6309 users will use LIST- 
ING 3 to set block $36 into memory for Z- 
bug to access, just like last time. 

Now that you have the screen block in 
memory, go into Z-BUG and byte mode. 
Change $FF99 to *08' and you will see that 
you now have a 32x24 screen with NO 
attributes. Look carefully at the screen, and 
you will see that the TEXT is in every other 
screen location, ^h strange characters 
in between. Remem- 
ber that before you 
changed $FF99, you 
were in the attribute 
mode, so text was 
written to the screen 
for that mode. 

By changing the 
value of $FF99, you 
set the non attribute 
mode, and the at- 
tribute byte is now be- 
ing displayed as a 
character! Press the 
'clear' key, and start 
sending ASCII codes 
to the screen, starting 
at $6000 with Z- 
BUG'S "slash" com- 
mand. It will take 
awhile for the screen 
to start scrolling, be- 
cause EDTASM uses 
SECB's screen rou- 
tine, which is still set 
up for 80x24- But you 
can see that when 
writing directly to the 
screen, every memory 
location is used for 
characters, while 
EDTASM is still send- 
ing them to every 
other location (as 
seen once the scroll 
catches up). So If you would like to use 
the NON attribute screen, I would recom- 
mend writing your own screen routine. 
Now play around with the other *$FF99 



values' to see the difference between them; 
it is quite interesting. Just a reminder, you 
will be typing BLIND, so type CAREFULLY 

In the 80x25 or 80x28 attribute mode, 
you can access lines 25 - 28 just like any 
other line (but not with SECB); write to 
them directly. Line 25 starts at $6F00, line 
26 at $6FA0, 27 at $7040 and 28 at $71 EO, 
with the screen ending at $717E. To re- 
turn to the REGULAR text screen, just 
change $FF99 to $1D. 

$FF9C seems to be some kind of verti- 
cal fine scroll register Values between 00 
and 07 will cause '1/8th' of a screen line to 
appear, per increment, at the bottom of 
the screen. A value of '07' will cause line 
24 to stay at the bottom of the screen at 
all times. It will not scrolL It is similar to 
the 80x25 column screen; but you only 
have 24 total lines. It too can be useful for 
important messages that stay on the 
screen. Its NORMAL value is '00'. 

$FF9D / $FF9E is the screen start off- 
set. $FF9D is like a 'coarse' adjustment 
and $FF9E is like a Une' adjustment Dur- 
ing TEXT mode, $FF9D is normally $D8, 
$FF9E is $00. I have discovered that by 
adding 04 to the value in $FF9D, you can 
change what is being displayed by 1 
'BLOCK'. For example: if $FF9D/9E is set 
to $0000, then BLOCK is being dis- 
played. With a value of $0400, block 1 is 
displayed, and so on (well only the first 
24-28 lines worth, depending on $FF99 as 
above). If you want to use this idea, I would 
recommend keeping a RAM image of 
$FF9D/9E, because they are not readable, 
(similar to $FF91 in part 1). LISTING 9 
will demonstrate this shortiy. 

By adding the value in TABLE 10's 
"FF9E adjust' column to the value in 
$FF9D/9E, you can move the display in 
the 'block' by one LINE. I don't know why 
the TF9E adjust" value is so small com- 
pared to the normal "line adjusf value, or 
why some of them are the same; I just 
found this out by accident But it is quite 
interesting and could possibly have some 
useful applications. To see what I mean, 
type in LISTING 9. save it to disk and as- 
semble it to memory. **** WARNING: This 
routine vwll WRITE to memory areas used 
by EDTASM and it's DOS. DO NOT 
WRITE ANYTHING TO DISK AFTER 



TABLE 11 


- SECB setup tables (all addresses and data are 


HEX) 




hard 


32 COLUMN 


40 COLUMN 


80 COLUMN 


GFX 




GFX 


$FF90 


E032 CC 


E03B 4C 


E044 4C 


E070 


4C 


E079 4C 


$FF98 


E033 00 


E03C 03 


E045 03 


E071 


80 


E07A 80 


$FF99 


E034 00 


E03D 05 


E046 15 


E072 


00 


E07B 00 


$FF9A 


E035 00 


E03E 12 


E047 12 


E073 


00 


E07C 00 


$FF9B 


E036 00 


E03F 00 


E048 00 


E074 


00 


E07D 00 


$FF9C 


E037 OF 


E040 00 


E049 00 


E075 


00 


E07E 00 


$FF9D 


E038 EO 


E041 D8 


E04A D8 


E076 


CO 


E07F CO 


$FF9E 


E039 00 


E042 00 


E04B 00 


E077 


00 


E080 00 


$FF9F 


E03A 00 


E043 00 


E04C 00 


E078 


00 


E081 00 
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RUNNING THIS PROGRAM, or a CRASH 
IS CERTAIN !!! **^ Turn off the computer 
and reboot t)efore using the disk. 

The routine will set up an 80x24 non- 
attribute screen (for easier reading of text), 
mark blocks - 59, and start displaying 
'BLOCK 00'. It doesn't mark blocks 60 - 
63 due to the ROMs being there, and need- 
ing the ROM routines (don't want to write 
over it's code). To 'PAGE' through each 
BLOCK, use the 'shift up or down arrows. 
To page through a particular block LINE 
by LINE, use the up or down an-ows. 

When paging line by line into another 
block, you will notice that the display is 
'out of sync' (the start of the next block Is 
not in the far left side). To correct this, 
pressing the 'CLEAR* key will reset the 
routine to the start of the LAST block that 
was set 

When you get to blocks 60 - 63, you 
can tell that they are the ROMs by looking 
at the text (you will see the copyright no- 
tices). Then the routine will recycle to block 
00 again, if you keep going in the same 
direction. 

With some imagination, this DEMO 
could be put to some useful purpose, its 
up to you. If you don't like the screen col- 
ors, just change $FFB0 = background 
$FFB1 = foreground, to the colors of your 
choice. Its strange how the non-attribute 
screen uses a background register for a 
foreground color. 

TABLE 8 shows what value to put into 
$FF9D/9E to start the display with a par- 
ticular block. Now, if by adding 04 to the 
value in $FF9D, you change the display 
by one block; then it goes that by adding 
02 to $FF9D, you will change the display 
start by a half block; 01 by a quarter block, 
etc. The use of adding 02 to $FF9D was 
used in PART 2 to set the 2nd half of the 
screen block (just thought you would like 
to know). 

You now have plenty to experiment with 
until the next installment. Along with 
PARTS 1 and 2, let your imagination go to 
woric! Next time, I will cover what I have 
found with graphics and more on the 
$FF9x registers. 

LISTING 9 $FF9x Demo program 

GO NOP 

LDD #$3030 ### 

STD NUM ###setbk)ck#to'00' 

LDA #$14 = 80x24 NGN-attribute mode 

STA $FF99 set it 

LBSR SETUP now go mark the blocks 

LDD #$0000 ### start with block *00' 
STORE STD TEMP 

save bkxk number olTset 
NEXT LDD TEMP gel current bkwk # offset 

STA $FF9D **sel 

STB $FF9E ** offset now 

JSR $A1C1 scan keyboard 

CMPA #$0A down arrow 7 



BEQ DOWN yes. scroll screen down 1 line 

CMPA #$5E up arrow? 

BEQ UP yes, scroll screen up 1 tine 

CMPA #$5F 'shift* up arrow? 

BEQ MUP yes, 'page' to next block 

CMPA #$5B 'shift' down arrow? 

BEQ MDOWN yes, 'page' to prevkxis 
bkxk 

CMPA #$0C 'clear* key? 

BEQ RESET yes, re-sync display 

CMPA #3 'break* key? 

BNE NEXT no. ignore all other keys 

LDD #$D800 address of standard screen 

STA $FF9D reset MMU for standard 

STB $FF9E text screen 

LDA #$1D standard value for $FF99 

STA $FF99 set ft now 

SWI EXIT toZ-BUG 
DOWN LDD TEMP get current offset 

SUBD #$0A bump to prevkxis line 

BRA STORE now go do it 
UP LDD TEMP get cunent offset 

ADDD #$QA bump to next line 

BRA STORE now go do it 
MDOWN LDD TEMP get current offset 

SUBA #4 bump to prevkxis page 

STD BLKSET save for reset routine 

BRA STORE go do it 
MUP LDD TEMP get cunent offset 

ADDA #4 bump to next page 

STD BLKSET save for reset routine 

BRA STORE go do it 
STRING LDA .X-t- get next character 

PSHS A save for stop test 

ANDA #$7F drop MSB 

STA , Y+ send it to screen 

TST , S+ was last character a 'stop* ? 

BPL STRING no, then kx)p for more 

RTS return 

SETUP LDA #$FF ** get ready 

STA BLOCK ** forbkx^k'OO' 
SETNXT LDA BLOCK get last bkx^ set 

INCA bump it by 1 
STA BLOCK save current bkx^ number 

CMPA #$3B last bkx)k to mark? 

BHt STOP yes, then stop 

STA $FFA3 set bkxk 

** $FFAB for E/A 6309 users 

LDY #$6000 = screen start 

LEAX TXT2,PCR get text to mark bk«k 

LBSR STRING go write it into bk»k 

LEAX NUM,PCR get bkx^k number 

LBSR STRING go write it into bkxjk 

LDD NUM get current bkx:k number 

ADDB #1 bump it by 1 

CMPB #$39 is 'units' higher thana9? 

BHI BUMP then fix to keep DECIMAL 

STD NUM save current block number 

BRA SETNXT go set next bkx^ 
BUMP LDB #$30 reset 'units' to '0' 

ADDA #1 bump tens' by 1 

STD NUM save cunent bkx^k number 

BRA SETNXT go marie next bkxA 
STOP LDA#$3B = original bk»k that 
needs to be put back 

STA $FFA3 put it back 

** $FFAB for E/A 6309 users 

RTS done -RETURN 

TXT2 FCC/ START OF BLOCK #/ ##- 
(note spaces) 

FCB $A0 = space -*■ stop code 
NUM FDB $3030 bkx^k number (decimal) 



FDB $2020 -spaces 
FDB $2020 = spaces 



FCB $A0 = space + stop code 
BLOCK RMB1 = bkx^ number (hex) storage 
BLKSET RMB2 = reset' routine storage 
TEMP RMB2 = 'offset* storage 
END 



LISTING 10 - 80x28 colunrm demo 

SECB =^ Super Extended Cok>r Bask; 
GO ORCC #$50 disable interupts 
CLR $FF91 setTR=0 
LDD #$3180= last screen line 
STD $F688 set last screen line in SECB 
LDD #$30E0^ line 27 
STD $F875 set it for SECB scroll routine 
LDD #$1C1B $1C = 27$1B = 28 
STA $F683 set SECB 
STB $F87F set SECB 
JSR $Fe79 do SECB's 80 column setup 

and clear screen 
LDB #1 

STB $FF91 *** set TR=1 
LDA #$7D = 80x28 column with 

attribute code 
STA $FF99 set it 
ANDCC #$AF enable intempts 
SWI EXIT backtoZ-BUG 
END 



LISTING 11 - 128 column demo 

^ This porlkxi sets up SECB for this routine *^ 

GO ORCC #$50 disable interupts 
CLR $FF91 setTR=0 
LDD #$7EF7 
STD $F824 *** 
LDA #2 

STA $F826 *** set intercept here 
LDD #$3800 = screen end address 
STD $F688 set it for SECB 
LDD #$3700 = last screen line start 
STD $F875 set it for SECB 
LDD #$0140= 128 character count 

(128+128 for attributes) 
STD $F870 set it for SECB 
LDA #$80 = max. characters per line 
STA $F681 set it for SECB 
JSR $F679 set SECB 80 column screen. 

clear screen 
LBSR MOVE move <C.R> intercept here 

for SECB to use 
LDB #1 ## 
STB $FF91 ##setTR==1 
LDA #$80 *** 

STA $FF9F *** set $FF9F for 128 column 
STA TMP9Fset RAM image of $FF9F 
ANDCC #$AF disable interupts 

*^ now data is entered thru tt)e keyboard and 
displayed to the screen 

POLL CLR$FF91 set TR=0 for ROM use 
JSR $A1B1 poll keyboard 
LDB #1 ## 

STB $FF91 ##setTR=1 for this routine 
BEQ POLL loop if no key pressed 
CMPA #$15 <shifl right anow> key? 
BEQ BACK yes. do scroll left routine 
CMPA #$5D <shift left am)w> key? 
BEQ FORWRD yes. do scroll right routine 
CMPA #3 <break>key? 
BEQ BREAKyes, exit this routine 
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CMPA #$0D <enter>key? 

BEQ ENTER yes, cto CR/ routine 

BSR DISPLA display any other key pressed 

6SR TEST check to see if cursor at far 

right of screen 
BRA POLL go for more entries 
DISPLACLR $FF91 set TR«0 
JSR [$A002] display character 
LDB #1 m 
STB $FF91 ##8etTR=1 
RTS return 

** see if 79 characters have been displayed. 
If 80, start scrolling the screen left until 128 
have been displayed. 

TEST LDB $FE02get SECB's character count 
CMPB #$4F displayed 79 characters y^ 
BLS D1 no. then exit 

LDA TMP9F get image of $FF9F 
INCA bump it for scroll left 

STA TMP9F save new value 
STA $FF9F cause scroll left by one 
character 

D1 RTS return 

** The <shift left ant>w> key will cause screen to 
scroll left no matter how many characters are 
displayed. 

BACK LOB TMP9F get RAM image of $FF9F 

CMPB #$B3 «# 

BHI B1 ##don1alk]fw a scroll further 
than this 

INCB bump it for scroll left 

STB TMP9F save new value 

STB $FF9F cause a scroll left 
B1 BRA POLL back to keyboard 

** The <shift right arrow> key will cause screen 
to scroll right 

FORWRD LDB TMP9F get RAM image 
of$FF9F 
CMPB #$80 ## 

BLS F1 ## scroll no further that this 
D EC B drop count t>y one 

STB TMP9F save new value 
STB $FF9F cause scroll right by 
one character 
F1 BRA POLL back to keyboard 

** The <enter> key will cause the screen to reset 
to ttie start (on the left margin) 

ENTER LDB #$80 start value for $FF9F 
STB TMP9F save new value 
STB $FF9F reset screen to left margin 
BSR DISPLA display last character 
BRA POLL back to keyboard 

*• Reset SECB to the nornial 80 column screen 
andexittoZ-BUG. 

BREAK CLR $FF9F set $FF9F back to 
80 columns 
ORCC #$50 disable intenipts 
CLR $FF91 set TR=0 to access ROMs 
LDD #$2E60 = last screen line start 
STD $F875 set it into SECB 
LDD #$2F00 == screen end address 
STD $F688 set it for SECB 
LDD #$00A0= max. characters per line 

for scroll 
STD $F870 set it for SECB 



LDA #$50 -max characters per line 

STA $F681 set it for SECB 

JSR $F679 do 80 column setup 

LDA #1 ## 

STA $FF91 ##setTR=1 for this routine 

ANDCC #$AF disable interupts 

SWI return to Z-BUG 

** This routine just moves DATA', so SECB can 
use it. 

MOVE LDX #$F702» destination of routine 

LEAYDATA,PCR == source of routine 

LDB #$10 
NXT LDA .Y+ *** 

STA ,X+ *** move routine to new k)catk)n 

DECB 

BNE NXT*** 

RTS done, return 

** This routine will reset the screen to ttie left 
margin when SECB sends a C.R. at the end 
of a line. The intercept was set at the start of 
this program. 

DATA PSHS B save *B* 
LDB #$80 = value to reset $FF9F 
STB TMP9F save new value in RAM image 
STB $FF9F set $FF9F to new value 
CLRA set up for original routine 

PULS B get this register 
JMP $F802 back to original routine 

TMP 9FRMB 1 = RAM image of $FF9F register 
END 




68K Performance Guide 

continued from page 13 

12. On original 68000-based cores it 
makes sense to exchange any shift larger 
than 16 bits with a swap, a smaller shift 
and maybe a clear For example: 

terl #18,Dn 
becomes 

clr.w Dn ; leave out if you don't mind 
a mess in the upper word 

sv^p Dn 

fsrl #2,Dn 

IV. PROBLEMATIC 

These are some hints that reduce code 
readability, portat>ility or have harmful side 
effects: 

1 . and's and or's (even immediate ver- 
sions) are very often faster than bit sets/ 
clears. 

2. Using Booth's algorithm for muttipti- 
cation by a constant will often be much 
faster than mul* instruction, but what do 
you do if this constant changes? You might 
be at)le to write a macro that generates 



Booth sequence for a given constant if your 
assembler has a powerful enough macro 
processor BTW, mul* instructions always 
affect the entire destination register re- 
gardless of the operation size. Use the 
slower long version only if you really have 
to. Try to express a division by a constant 
as a multiplication fc)y a constant and divi- 
sion by a constant power of two (shift right, 
see also 111.12). For example, a division 
by 12 can be expressed as a multiplica- 
tion by 85 and division by 1024 (shift by 
10): 

move.l Dn.Dm 

tsl.l #2,Dm ; make this 2 adds on 
anything better than original 6d000-based 
core, (see III.9) 

add.1 Dm,Dn ; Dn = Dn * 5 

move.l Dn.Dm 

Isl.l #4, Dm 

add.) Dm.Dn ; Dn = Dn * (5 + 5 * 16) 
= Dn * 85 

Isr.l #10.Dn ; Dn = Dn * 85 / 1024 

3. On original 68000 and derivative 
cores, 'moveq#0,Rn' is faster than dr. How 
ugly. 

4. Don't use any 'non-quick' immediate 
instructions in a loop, try to pre-load ev- 
erything into a register. 

5. Fast CPU32 polling: 
moveq #-1,Dn 

moveq #READYBIT,Dm ; static btst 
can't be loop-moded, see II 1. 7 
poll: 

btst Dm,some_memory- 

mapped_device_register 

dbne Dn.poll 
of course, using III.2 we can speed it up 
even more if the signalling bit happens to 
be bit 7,15 or 31: 

moveq #-1,Dn 
poll: 

tst.x some_memory- 

mapped_device_register 

dbmi Dn,poll 
This is very fast because the loop mode 
is utilized and dbcc is perfect for overiap- 
ping access to the device register which is 
probably even slower than regular 
memory. The problem is that it will fail if 
Dn ever wraps around (after 65K Itera- 
tions). 

V. NEEDED 

So, which CPU32 instructions have 
tails? I understand any access to memory, 
but not the source in move, but I am not 
sure. If you have any additions, e-mail me 
or write this magazine. 
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RGBoest-$1S.OO 

tf you want to speed up DECB easily, install an Hitachi 
6309 and get RGBoost. This patch for DECB uses the ex- 
tra 6309 functions for up to a 1 5% gain in overall speed. It 
is compatible with all programs tested to date! Save an 
additional $5 by purchasing RGBoost along with one of 
my other products listed below! 

■PffAgM63ay vxoa - tag.QO 

Patches Tandy's Disk EDTASM to support Hitachi 6309 codesl Sup- 
ports all CoCo models, including stock 6809 models. CoCo 3 ver- 
sion uses 80 column screen, runs at 2MHz, YOU MUST HAVE A 
COPY OF DISK EDTASM. This is a B*TCH ONLY! It will not work 
with 'disk patched' cartridge EDTASM 

Receive and print weather fascimile maps from short\^ovel The US 
weather service sends them all the timel Requires 51 2K CoCo3 
and shortwave receiver. Instructions for simple cable included. 

twfppf-$ag>oo 

Move programs and data between DECB and OS-9 disks! Sup- 
ports RGB- DOS - move files easily between DECB and OS-9 par- 
titions! No modifications to OS-9 modules required. 

DIM SBiortWaidi PHvf - >20,00 

Access your SmortWotch from DEC61 Adds function to BASIC 
(DATES) for accessing date and time. Only $15.00 with any other 
purchase! 

Kobcrti Gault 

532 N. Kenaud 

Groeee Fo\nte Woode, Ml 4&236 

313-&S1-0335 

Please add $4 S&H per order 



for all your CoCo hardware needs, connect with 



€o9lEt 



1629 South 61st Street 
^r|1 West Allis.WI 53214 
J m (pulland@oinnifest.uwm.edu) 



That thing that Tandy calls a serial port on the CoCo 
has always been a problem. It was designed with 
minimal cost in mind, and never upgraded. Even 
Tandy tried to fix it with their RS-232 Pak, but even it 
was only half done! Our Fast 232 port uses a 1 6 byte 
buffer at alleviate missed characters at any speed and 
also has ALL RS-232 lines implemented. It Is easy to 
set up with jumpers for different addresses. A 
daughterboard can be purchased to easily add a 
second fast serial port! And all this in a cartridge the 
size of a ROM Pak! 6809 and 6309 OS-9 drivers in- 
cluded. Completely supports up to 57.600 bps, lim- 
ited support for 1 1 5,000 bps. 

Fast 232 - $79.95 
Daughter Board - $45.00 

Check with us for complete disk drive systems, 
misc. hardware items, hardware repairs, and hard 
to find new and used CoCo software! 



StrongWare 



Box 361 Matthews, IN 46957 Phone 317-998-7558 

CoCo 3 Software: 

Soviet Bloc $15 

GEAAS $20 

CopyCct $5 

HFE- HPrint Font Editor $ 1 5 

MAA/l Software: 

Graphics Tools $25 

Starter Pak $15 

BShow $5 

CopyCat $10 

Painter $35 
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What are vou waitins for? 

Get your friends to subscribe to 

the only magazine that still supports 

the Tandy Color Computer... 

''the world of 68' micros*'\ 

The more people who want the suoDort* 

the longer it will be here! 
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